Internet Surfer 2.0

home *** CD-ROM | disk | FTP | other *** search

/ Internet Surfer 2.0 / Internet Surfer 2.0 (Wayzata Technology) (1996).iso / pc / text / mac / faqs.342 < prev next >

Wrap

Text File | 1996-02-12 | 27.8 KB | 611 lines

Frequently Asked Questions (FAQS);faqs.342 6. Which LAN technology should I use? Arcnet? FDDI? Token Ring? 10BASE-T? A controversial question. Some questions & answers from the 12/91 BIG-LAN Reader Survey: "When you install a LAN, which "Technology" (e.g. Ethernet, Token Ring) do you prefer?" 37 responders said Ethernet; 2 said "pick one and stick with it"; 1 said token ring. "If you have experience with two or more LAN technologies, which have you found works better?" Answers received: "Ethernet works best" 7 "Ethernet works better than Token Ring" 4 "Depends on application" 1 "Ethernet works better than ARCnet" 1 "Ethernet works better than Broadband" 1 "Ethernet best, Localtalk 2nd, ARCnet 3rd" 1 "Ethernet works better than PhoneNet" 1 "Token Ring works best" 1 7. What is the ideal cable to install in a new building? Distribution runs, i.e., phone closet to room: Best possible thing to do is to leave usable pathways for future expansion. Whatever you do, install at least 2 pair and probably 4 pair of data grade unshielded twisted pair. It will always have uses. Install something else too if you are tied to a particular vendor. Multimode fiber might become popular in the future but that is a gamble. Riser runs, i.e., phone closet to phone closet: it is imperative to leave usable pathways for future expansion. For Ethernet, ThinWire is a usable riser cable, multimode fiber is possible too. 8. What is the ideal cable to install between buildings on a campus? Trunks, i.e., cables into the building: pathways for future expansion very valuable. Multimode fiber is useful, run 24 fibers if you can. Use cable with some single mode too. Run several times what you need initially and leave a lot of the unused fiber unterminated for the time being. Cable pulling & termination are much more costly than the cable itself. 9. Whose routers are recommended? Question & answer from the 12/91 BIG-LAN Reader Survey: "Name some router vendors whose routers you have used and recommend:" Cisco got 30 mentions; Wellfleet 4; PCRoute 2; Proteon 2; Apple 1; DEC 1; Network Systems 1; Shiva 1; Vitalink 1; 3COM 1. 10. Whose bridges are recommended? Question & answer from the 12/91 BIG-LAN Reader Survey: "Name some bridge vendors whose routers you have used and recommend:" DEC got 6 mentions; Retix 5; BICC 3; Cabletron 3; 3COM 3; Cisco 2; PCBridge 2; Vitalink 2; ACC 1; Clearpoint 1; Datability 1; Develcon 1; Dowty Scanet 1; HP 1; IBM (Token Ring) 1; Network Application Technology 1; PCBRoute 1; Wellfleet 1. 11. Whose Ethernet equipment are recommended? Question & answer from the 12/91 BIG-LAN Reader Survey: "Name some Ethernet concentrator/transceiver/repeater vendors whose Ethernet equipment you have used and recommend:" Cabletron got 20 mentions; BICC 8; DEC 8; HP 4; Synoptics 4; David 3; Lantronix 3; Gandalf 2; Lannet 2; Pirelli Focom 2; Acton 2; Allied Telesys 1; AMP 1; Asante 1; Chipcom 1; Dowty Scanet 1; Dupont Electroptic 1; EAZY 1; Fibermux 1; Hirschmann 1; IMC Network Corporation 1; NetCor Transceivers 1; Sension 1; 3COM 1. 12. Whose Token Ring equipment are recommended? Query and answers from the 12/91 BIG-LAN Reader Survey: "Name some Token Ring equipment vendors whose Token Ring equipment you have used and recommend:" IBM was mentioned by 6 responders; FiberMux 1; Madge 1; Synoptics 1. 13. Whose FDDI equipment are recommended? Query and answers from the 12/91 BIG-LAN Reader Survey: "Name some FDDI equipment vendors whose FDDI equipment you have used and recommend:" Cisco was mentioned by 6 responders; DEC 2; Tymeplex 2; ALCATEL 2; AT&T 1; Synernetics 1; Tekelec 1. 14. What PC network software is recommended? Query and answers from the 12/91 BIG-LAN Reader Survey: "Name some PC network software vendors whose PC network software you have used or recommend:" Novell was mentioned by 19 responders; FTP Software 14; Sun 8; DEC 3; Apple 2; Farallon 2; InterCon 2; 3COM 2; Beame and Whiteside 1; Hummingbird Communications 1; IBM 1; Microsoft 1; NCSA 1; Neon Software 1; Network Application Technology 1; Sitka 1. 15. What protocols should run on a campus-wide LAN? Query and answers from the 12/91 BIG-LAN Reader Survey: "Name some protocols that you use to interconnect your campus that you would recommend:" TCP/IP was mentioned by 39 responders; Appletalk 9; DECNET 9; IPX 9; LAT 2; Coloured Book 2; G.703 2; ISO CONS 2; X.25/HDLC 1; XNS 1. 16. What software is recommended for managing a campus-wide LAN? Queries and answers from the 12/91 BIG-LAN Reader Survey: "Name some network management system that you use for the management of a campus LAN, that you recommend:" PSI SNMP was mentioned by 4 responders; Cabletron Remote LanView 2; Cisco NetCentral 2; Proteon Overview 2; SNMP 2; "A good drawing program" 1; DEC EMA 1; Map 1; NEMISYS from SEEL 1; SunNet Manager 1; TRW NMS 1. "Name other software that you use for the management of a campus LAN that you recommend:" FTP LanWatch was mentioned by 3 responders; EtherPeek 2; ping 2; AG Group Net Watchman for Appletalk 1; Apple Interpoll 1; Clarkson Packet Driver Utilities 1; DEC LAN Traffic Monitor 1; Domain Name System 1; inetrover 1; LAN Patrol 1; Neon Software Netminder Localtalk 1; Neon Software Netminder Ethernet 1; Network Application Technology EtherMeter 1; Shiva Net Manager 1; SNMP-Gawk (A SNMP-capable Gawk) 1; traceroute 1; Unix 1; Watchdog 1. 17. What terminal server is recommended? Query and answers from the 12/91 BIG-LAN Reader Survey: "Name vendors of terminal servers that you use and recommend:" Cisco was mentioned by 13 responders; DEC 5; Xyplex 4; Datability 2; Xylogics 2; 3COM 2; Emulex 1; Lantronix 1; Netcomm 1; Spider 1; TRW 1. 18. Whose troubleshooting equipment are recommended? Query and answers from the 12/91 BIG-LAN Reader Survey: "Name some vendors of network troubleshooting equipment that you use and would recommend:" Network General was mentioned by 8 responders; HP 4; Tektronix 4; Cabletron 3; Novell 3; Spider 3; AG Group 2; Wandel and Goltermann 2; FOTEC 1; Neon Software 1. 19. What security products should I buy? Query and answers from the 12/91 BIG-LAN Reader Survey: "Name some security products that you use to maintain security on your campus LAN that you recommend:" The answers reflected the lack of obvious products to choose from. Responses included "Athena Kerberos", "Encryption in Net3270", "Extended TACACS', "Host security", "Physical security", "Router access control lists", "SecurID", "Virus Scan", and "Windows Workstation". 20. Should the names of devices on my campus LAN have subdomains? Example of name without subdomain: bigvax.sequoia.edu; example with subdomain: bigvax.acs.sequoia.edu. It is possible to run networks of thousands of computers without the bother of subdomains, but they have some advantages. Queries and answers from the 12/91 BIG-LAN Reader Survey: "For Internet names of nodes on a campus network that supports TCP/IP, do you prefer the use of subdomains?" 27 responders said yes, 5 said no, 2 said it depends. "If you have worked on a campus that utilizes subdomains and one that does not, which does your experience tell you is the better way to administer names in a campus network?" 5 responders said the LAN with subdomains worked better; 2 said the LAN without subdomains worked better. One responder claimed that a good rule of thumb is that a LAN with more than 4000 stations works better with subdomains. 21. Should client stations use POP? Should they use just SMTP? Should I use some non-TCP/IP protocol for mail to/from client stations? Query and answers from the 12/91 BIG-LAN Reader Survey: "For client station's mail, which do you prefer: SMTP; TCP/IP-based client-server protocols (e.g. POP, POP2, etc); other LAN protocols?" 10 responders preferred TCP/IP-based client-server protocols (e.g. POP, IMAP, PCMAIL); 7 preferred SMTP; 4 said "use all three"; 3 preferred users signing onto a host system; 2 preferred other LAN protocols; 1 said "SMTP and TCP/IP-based client-server protocols"; 1 said "SMTP and X.400". 22. Should I enable SQE/heartbeat? This is a very brief discussion of SQE and CPT (both commonly referred to as "heartbeat") for IEEE 802.3 and Ethernet. For really gory details, see the appropriate documents, IEEE standard 802.3, ISO standard 8802-3, and the DIX Ethernet V2 Standard. (The first 2 references are, in theory, identical.) First, SQE and CPT are not quite the same thing. CPT is a part of DIX Ethernet Version 2 and is simply a test of collision detection functionality in the MAU (that's the correct name for a transceiver, Media Access Unit). It is ALWAYS present in Ethernet V2 MAUs and can't ever be disabled (without modifying the hardware). It is required for correct operation of ALL Ethernet V2 equipment. SQE, on the other hand, is part of the 802.3 specification and performs basic MAU tests and "reports" to the controller if all is well. The "report" is in the form of a pulse nearly identical to the V2 CPT pulse, but with slightly differing timing specifications. It should be switchable, as 802.3 requires SQE for all terminal equipment, but prohibits it for repeaters. SQE and Heartbeat both appear as a signal in the collision lines from the MAU to the controller after every write. This is why MAUs with SQE enables and with displays show a collision every time they show a write. THIS IS NORMAL! Quick digression: What is a collision? Of course, we all know that a collision is when two controllers start to transmit at the same time (more of less) and that when this happens both will stop and wait for a random interval and then retransmit if carrier is not present. This function is critical to proper network operation. A MAU which can't detect a collision can mess up a network badly. This makes it critical to be able to quickly isolate "broken" MAUs. If you don't understand this, read any of the old papers on multiple access nets, especially the old Aloha Net. Collisions are a normal part of Ethernets. There is nothing "wrong" with having collisions. The name seems to make people think that they are somehow bad. If you start to feel that way, say to yourself 20 times before going to be tonight: "Collisions are my friend." Having said all of that, there is one type of collision that is NOT your friend. The "Late Collision". This is a collision which is generated more than 60 bytes into a packet. Since the is "impossible", it indicates that something is seriously wrong. Too long a cable, a bad MAU, or some other hardware problem. IF you are getting late collisions, you are also likely corrupting packets without knowing it because collisions are not being properly detected. In practice, MAUs hardly ever fail. BUT IF ONE DOES, YOU MAY HAVE A BIG PROBLEM! While SQE indicates a bit more than heartbeat did and is slightly different in both timing and electrical characteristics, they are essentially the same from the perspective of most terminal equipment and you can replace an Ethernet V2 MAU with an 802.3 MAU with SQE enabled most of the time. (A notable exception is an Ethernet repeater which really requires an Ethernet V2 MAU. There may be others.) You can even replace an 802.3 MAU with an Ethernet V2 one most of the time. In fact, there are "fixes" for some Ethernet V2 MAUs to disable heartbeat and make them into something like an 802.3 MAU with SQE disabled. This also seems to work almost all the time. Anyone still with me? OK. RULE FOR SQE. Always turn it on except for repeaters. There should be no exceptions to this rule, but there are. Some manufacturers can't seem to read standards (or just don't care). As a result there are some terminal devices that get upset when they see SQE. I have been told that this is true of the cisco AGS, but not the IGS; not that there is any documentation on this. Several email exchanges with cisco folks have not clarified this. There is one BIG special case, the Etherrnet fan-out box, most commonly a DEC DELNI. This box has only one MAU, so it repeats the CPT (it's a V2 device) that it sees from the MAU on the "master" port. If the master port is disabled, CPT is generated internally to keep things happy. But, what if you plug a repeater into a DELNI? You can disable CPT by using an 802.3 MAU with SQE disabled. or, if you don't use the master port, turn it on and plug an Ethernet loopback connector into the master port. In either case, CPT is disabled to ALL PORTS! No way around this. DELNIs produce other oddities. They reduce the maximum segment length on segments connected to the master port to 300 meters and shorten the maximum length of the AUI cable used between the system and the DELNI by 5 meters. (And don't forget to include the length of the cable between the interface and the connector on the rear of the cabinet.) Because of these and other oddities, I try to avoid DELNIs. And I NEVER EVER plug a repeater of any type into one. Other companies make 802.3 equivalents to the DELNI on which SQE may be switched on each port. While this fixes one problem, the timing concerns of fan-out boxes remains. Buyer beware! Neither 802.3 nor Ethernet V2 standards cover fan-out boxes in any way, so there is no way to really claim that they meet standards (or don't). We've now covered the basics. So what happens when a MAU fails? In theory, every time it transmits a packet, an error is logged. This happens on some equipment. But most software I've dealt with simply ignores the error flag and does nothing. So SQE makes absolutely no difference to these systems. THIS IS BAD SOFTWARE DESIGN. Once in a while a MAU does fail. If it is on some device that does not log SQE failures or has a MAU with SQE turned off, you don't know what is happening. If you are on 10BASE-T, it can be isolated to a hub pretty quickly, but on coax you are reduced to segmenting the cable (physically disconnecting it) until you have isolated the problem. This is NOT fun and makes the network manager very unpopular since the network tends to be down for a LONG time. It took about 4 hours last time I had this problem and could have taken longer. What's a network manager supposed to do? Complain vigorously to vendors of equipment that don't adhere to the standard. Complain equally to vendors of software that doesn't bother to log the failures. SNMP is no good if the agents don't have any information to send out. End of Memo: BIG-LAN Frequently Asked Questions Xref: bloom-picayune.mit.edu comp.mail.misc:10271 news.answers:3545 Newsgroups: comp.mail.misc,news.answers Path: bloom-picayune.mit.edu!snorkelwacker.mit.edu!micro-heart-of-gold.mit.edu!wupost!zaphod.mps.ohio-state.edu!rpi!scott.skidmore.edu!psinntp!psinntp!newstand.syr.edu!spider.syr.EDU!jmwobus From: jmwobus@mailbox.syr.edu (John Wobus) Subject: LAN Mail Protocols Summary Message-ID: <1992Oct16.133537.19263@newstand.syr.edu> Followup-To: poster Originator: jmwobus@spider.syr.EDU Reply-To: jmwobus@mailbox.syr.edu Organization: Syracuse University, Syracuse, NY Date: Fri, 16 Oct 92 13:35:37 EDT Approved: jmwobus@mailbox.syr.edu Lines: 198 Archive-name: LANs/mail-protocols Serving PCs and Workstations Using a Central Mail Server on an Internet ------- --- --- ------------ ----- - ------- ---- ------ -- -- -------- There are advantages to collecting mail destined to PCs and workstations on a central server, to be turned over to the PC or workstation on demand: - Your PC or workstation may be down quite a bit and less network bandwidth and less of the processing resouces of the sending computer are used if the computer receiving your mail is ready. - Some people use more than one PC or workstation to read mail. - A PC or workstation may not have the resources to store all the mail you receive. - It can make your e-mail address more like other users'. The easiest way to "implement" this is to run the central mail server like any multi-user system: let people sign on to it and use some mail utility. Then PC and workstation users can use "terminal sessions" to sign on to the central mail server and read their mail. This has the disadvantage of making the PC and workstation users learn and use the central mail server's procedures. SMTP, the "internet" mail protocol used to deliver mail between multi-user systems only supports mail transfer initiated by the sender. Other protocols have been devised to allow a workstation or PC to request transfer of mail, thus able to make use of a cnetral server. These include the published protocols POP (probably not used anymore), POP2, POP3, IMAP2, IMAP3 and DMSP. POP, POP2, POP3: These are rather minimal and are designed to be so. The three are similar but not enough alike to be interoperable. They are basically designed to identify the user by username and password, to transfer the mail from server to PC or workstation and to delete the mail transferred. It is assumed that SMTP will be used to send mail. Messages can be retrieved individually, but the only information you can get about a message without transferring it is its length in bytes-- useful for PCs with limited storage. POP2 and POP3 are still used a good deal. POP3 has a couple of optional extensions: one to avoid sending passwords, and one to aid in reading bulletin boards. IMAP2, IMAP3: The IMAP family is similar to the POP family, but also gives clients a way to do string searches through mail that still resides on the server. This is designed to allow the PC or workstation to be more selective as to which mail will be transferred. The POP protocols, on the other hand, are designed for simpler server software. IMAP2 is used quite a bit. IMAP3 is an incompatible offshoot that has not been implemented much. Recent work not yet documented in an RFC has extended IMAP2 to include support for multimedia mail. DMSP (aka PCMAIL): PCs and workstations can use this protocol to both send and receive mail. The system is designed around the idea that each user can own more than one workstation; however, the system doesn't seem to handle the idea of a "public workstation" very well. The PCs and workstations are assumed to hold state information about the mail, a directory so to speak, and when the PC or workstation is connected to the server, this directory is updated to "reality". More about the protocols: Name: Post Office Protocol, Version 2 Nickname: POP2 Document: RFC 937 (Butler et al, February 1985) TCP-port: 109 Sites: Name: Post Office Portocol, Version 3 Nickname: POP3 Document: RFC 1225 (Rose, May 1991) TCP-port: 110 (109 also often used) Sites: UC Irvine, MIT Name: Distributed Mail Service Protocol Nickname: DMSP, Pcmail Document: RFC 1056 (Lambert, June 1988) TCP-port: 158 Sites: MIT Name: Interactive Mail Access Protocol, Version 2 Nickname: IMAP2 Document: RFC 1176 (Crispin, August 1990) TCP-port: 143 Sites: Stanford, U Washington Name: Interactive Mail Access Protocol, Version 3 Nickname: IMAP3 Document: RFC 1203 (Rice, February 1991) TCP-port: 220 Sites: Stanford Implementations: Prot Computer Implementation End Source ------ ----------- ------------------- ------- -------------------------------- DSMP PC pc-epsilon (3.1) client allspice.lcs.mit.edu DSMP PC pc-netmail (3.1) client allspice.lcs.mit.edu DSMP PC pc-reader client allspice.lcs.mit.edu DSMP Unix Pcmail 3.1 reposit. server allspice.lcs.mit.edu DSMP Unix/EMACS Pcmail 4.2 client allspice.lcs.mit.edu DSMP PC PC/TCP client FTP Software DSMP OS/2 PC/TCP client FTP Software DSMP OS/2 TCP/2 client Essex Systems DSMP OS/2 TCP/2 SERVER PACK server Essex Systems DSMP OS/2 TCP/2 ADV CLIENT client Essex Systems IMAP2 Macintosh MacMS 2.2.1 client sumex-aim.stanford.edu IMAP2 Macintosh Mailstrom (beta) client sumex-aim.stanford.edu POP2 Macintosh MacPOP 1.5 client trident.arc.nasa.gov POP2 MS-DOS PC POP 2.1 client trident.arc.nasa.gov POP3 Macintosh TCP/Connect II client InterCon Systems Corporation IMAP2 NeXT EasyMail client ftp.cac.washington.edu IMAP2 NeXT MailManager server ftp.cac.washington.edu IMAP2 TOPS20 ? server ? IMAP2 Unix ? client ftp.cac.washington.edu IMAP2 Unix imapd 3.1 server sumex-aim.stanford.edu* IMAP2 Unix/X ximap 0.7.2 client sumex-aim.stanford.edu IMAP2 Unix imapd server ftp.cac.washington.edu IMAP2 Unix pine client ftp.cac.washington.edu IMAP2 Xrx Lsp Mch ? client ? IMAP2 MS-DOS pine (future) client ? IMAP2 MS-Windows ? client ?Some company in Canada POP2 Macintosh POPMail II client boombox.micro.umn.edu POP2 Macintosh MailStop server boombox.micro.umn.edu POP2 MS-DOS LifeLine Mail client SunSelect POP2 MS-DOS ka9q server ucsd.edu POP2 MS-DOS MD/DOS-IP client U Maryland POP2 MS-DOS PC/TCP client FTP Software POP2 Unix ? server boombox.micro.umn.edu POP2 Unix popd (USC-ISI) server trident.arc.nasa.gov POP2 Unix imapd/ipop2d server ftp.cac.washington.edu POP2 Unix mh-6.7 (UCI RandMH) server ftp.cc.berkeley.edu POP2 VM FAL server IBM POP2 VM ? server Texas Tech University POP2 OS/2 TCP/2 SERVER PACK server Essex Systems POP2 VMS MULTINet server TGV, Inc. POP3 Macintosh Eudora 1.2.2 client ftp.cso.uiuc.edu POP3 Macintosh Eudora 1.3 (in dev) client Not Yet POP3k Macintosh Eudora X client run at Brown U. POP3 Macintosh MacPOP (Berkeley) client ftp.cc.berkeley.edu POP3k Macintosh TechMail 2.0 client net-dist.mit.edu POP3 Macintosh MacMH client jessica.stanford.edu/info POP3 Macintosh POPMail II client boombox.micro.umn.edu POP3 Macintosh MailStop (soon) server UMinn POP3t Unix popper-1.7 server ftp.cc.berkeley.edu POP3 Unix popper-1.831 server ? POP3 Unix mh-6.7 (UCI RandMH) both ics.uci.edu POP3 Unix imapd/ipop3d server ftp.cac.washington.edu POP3t MS-DOS PC/TCP client FTP Software POP3 MS-DOS TechMail(future) client ? POP3 MS-DOS ? client logos.ucs.indiana.edu POP3 MS-DOS NUPOP (in beta) client (ftp.acns.nwu.edu) POP3 MS-DOS POPMail/PC client boombox.micro.umn.edu POP3 MS-DOS Eudora (alpha) client Qualcomm Inc (pc-eudora-info@qualcom.com) POP3 MS-DOS ka9q (future) server ? POP3 ? POPgate (Pmail gw) server risc.ua.edu POP3x MSwindows WinQVT (2.1) client QPC Software (shareware) POP3 MSwindows Eudora (future) client Qualcomm Inc (pc-eudora-info@qualcom.com) POP3 MSwindows wnqvtnet client ftp.cica.indiana.edu POP3 VMS IUPOP3 (1.7) (1.6?) server mythos.ucs.indiana.edu, logos? POP3 VMS MULTINet both TGV, Inc. POP3 OS/2 TCP/2 SERVER PACK server Essex Systems POP3 OS/2 TCP/2 ADV CLIENT client Essex Systems POP? MS-DOS UCDmail client ucdavis.ucdavis.edu POP? MS-DOS PC POP client ?Bill Schweickert/Sterling Fed POP? Macintosh MEWS client ? POP? Macintosh byupopmail client ? POP? VM ? server TTUVM1 ? Macintosh Hypermail ? ? ------ ----------- ------------------- ------- -------------------------------- Appendix: Some other packages for desktop systems ------ ----------- ------------------- ------- -------------------------------- uucp Macintosh uAccess peer ICE Engineering SMTP Macintosh LeeMail 1.2.4 peer Shareware, laf@mitre.org uucp Macintosh FernMail peer Shareware, dplatt@snulbug.mtview.ca.us prop Macintosh MacPost both ftp.lu.se uucp Macintosh Eudora peer ftp.cso.uiuc.edu uucp Macintosh UUPC peer dplatt@snulbug.mtview.ca.us uucp Macintosh gnuucp peer jim@fpr.com ? MS-DOS Pmail 2.3 (R1) client splicer.cba.hawaii.edu ? MS-DOS Pmail 2.3 (R2)(fut) client ? MS-Windows Pmain/Windows (fut) client ? Macintosh Pmail/Mac 1.1 client splicer.cba.hawaii.edu ? Macintosh Pmail/Mac 2.0(beta) client risc.ua.edu ------ ----------- ------------------- ------- -------------------------------- Other issues: (1) What are the common extensions to POP3 and which clients/servers support them? POP3k - kerberos POP3x - ? POP3t - xtnd xmit facility--allows client to send mail through additional POP commands, thus allowing server to verify/log source of mail. ------ ----------- ------------------- ------- -------------------------------- Xref: bloom-picayune.mit.edu comp.os.linux.announce:37 comp.os.linux:20812 news.answers:4588 Newsgroups: comp.os.linux.announce,comp.os.linux,news.answers Path: bloom-picayune.mit.edu!enterpoop.mit.edu!news.media.mit.edu!micro-heart-of-gold.mit.edu!xn.ll.mit.edu!ames!saimiri.primate.wisc.edu!caen!batcomputer!db.TC.Cornell.EDU!mdw From: mdw@db.TC.Cornell.EDU (Matt Welsh) Subject: [comp.os.linux.announce] Guidelines for posting Message-ID: <1992Dec14.202427.14323@tc.cornell.edu> Followup-To: poster Keywords: announce posting guidelines Sender: news@tc.cornell.edu Nntp-Posting-Host: db.tc.cornell.edu Organization: The Linux Inquisition, Propaganda Division Date: Mon, 14 Dec 1992 20:24:27 GMT Approved: linux-announce@tc.cornell.edu (Matt Welsh) Lines: 111 Archive-name: linux-faq/announce/guide Last-modified: 6 Dec 1992 HOW TO POST TO COMP.OS.LINUX.ANNOUNCE This article gives info on how and what to post to comp.os.linux.announce. Please read the whole thing, to avoid any confusion. :) To submit an article to this group, please mail the article to: linux-announce@tc.cornell.edu If you have questions or problems with posting to comp.os.linux.announce, please send mail to the moderators at: linux-announce-request@tc.cornell.edu Or, you may send mail to us directly. The moderators for this group are Matt Welsh (mdw@tc.cornell.edu) and Lars Wirzenius (wirzeniu@cc.helsinki.fi).